DevLog AI : concevoir une architecture IA avant d'intégrer un modèle de langage
Une nouvelle étape : construire la mémoire technique d'un projet
Après plusieurs mois consacrés au développement de Trading OS, un second projet est progressivement devenu un pilier de mon portfolio : DevLog AI.
À première vue, il pourrait être facile de résumer ce projet comme une plateforme utilisant un modèle de langage pour analyser du code. Pourtant, ce n'est pas son objectif.
Aujourd'hui, des outils comme ChatGPT, Codex ou d'autres assistants de développement sont capables de générer du code, d'expliquer une architecture ou de proposer des corrections en quelques secondes.
La véritable question est donc devenue :
Pourquoi construire DevLog AI alors que ces agents existent déjà ?
La réponse est simple : parce qu'un agent IA est excellent pour travailler dans le présent, tandis qu'un projet logiciel s'inscrit dans le temps.
Une architecture, une décision technique ou un compromis réalisé plusieurs mois auparavant disparaissent rapidement des conversations. DevLog AI est né de cette idée : construire une mémoire technique durable, capable d'accompagner aussi bien les développeurs que les agents IA.
Cet article revient sur les choix techniques réalisés, les enseignements tirés de cette première étape et la vision qui guidera les prochaines évolutions du projet.
Le contexte
Au fil du développement de Trading OS, un constat est rapidement apparu.
Les décisions importantes étaient dispersées :
- dans les conversations ;
- dans les commits Git ;
- dans les fichiers de documentation ;
- dans les ADR (Architecture Decision Records).
Cette documentation existait, mais elle n'était ni centralisée, ni exploitable automatiquement par un agent IA.
L'objectif de DevLog AI est donc de transformer ces différentes sources d'information en une connaissance structurée et exploitable.
L'idée n'est pas de remplacer les développeurs ni les outils existants, mais de leur fournir un contexte durable afin qu'ils puissent prendre de meilleures décisions.
Les principales réalisations
Cette première phase du projet a permis de mettre en place les fondations de la plateforme.
L'architecture repose désormais sur deux services spécialisés.
Java Core
Le Java Core constitue le cœur métier de l'application.
Il est responsable de :
- la gestion des projets ;
- la construction des contextes d'analyse ;
- l'orchestration des workflows ;
- la persistance des connaissances ;
- la validation des propositions générées par l'IA.
Toutes les décisions métier restent centralisées dans ce service.
Python AI Engine
Le second service est développé avec FastAPI.
Son rôle est volontairement limité.
Il reçoit un contexte d'analyse préparé par le Core, construit un prompt adapté, interroge un fournisseur de modèle de langage puis renvoie une réponse structurée.
Il ne possède aucune connaissance métier et n'accède jamais directement aux données du projet.
Une communication asynchrone
Les deux services communiquent à travers une API REST asynchrone.
Le Java Core construit un AnalysisContext, crée une tâche d'analyse puis la transmet à l'AI Engine.
Une fois le traitement terminé, le moteur Python renvoie uniquement une proposition structurée.
Le Core reste alors responsable de sa validation et de sa persistance.
Les choix d'architecture
L'une des décisions les plus importantes concerne la place de l'intelligence artificielle dans l'application.
De nombreux projets construisent leur architecture autour du modèle de langage.
DevLog AI adopte l'approche inverse.
Le modèle de langage n'est pas le cœur du système.
Il constitue simplement un composant interchangeable derrière une abstraction.
Le Java Core reste responsable :
- du domaine métier ;
- de la connaissance du projet ;
- de la construction du contexte ;
- des règles métier ;
- de la validation ;
- de la persistance.
Le moteur Python reste responsable :
- de la construction des prompts ;
- de l'appel au fournisseur IA ;
- de l'interprétation du contexte.
Enfin, le modèle de langage ne possède qu'une seule responsabilité :
interpréter le contexte fourni.
Cette séparation permet de conserver une architecture robuste tout en restant indépendant d'un fournisseur particulier.
Plus qu'un agent IA : une mémoire technique
La réflexion qui a guidé DevLog AI est finalement assez différente de celle de nombreux outils actuels.
Les agents IA savent déjà :
- générer du code ;
- proposer des corrections ;
- expliquer une fonction ;
- écrire des tests.
En revanche, ils ne constituent pas une mémoire d'ingénierie.
Ils ne connaissent pas naturellement :
- les décisions d'architecture prises plusieurs mois auparavant ;
- les compromis acceptés par l'équipe ;
- les conventions propres au projet ;
- les raisons ayant conduit à certaines implémentations.
DevLog AI cherche précisément à combler cet écart.
L'objectif est de centraliser ces informations afin de fournir aux agents IA un contexte riche, cohérent et durable.
Le code généré devient alors plus pertinent parce qu'il est produit en tenant compte de l'histoire du projet, et non uniquement de son état actuel.
Un nouveau workflow de développement
Le développement de DevLog AI a également fait évoluer ma manière de travailler.
Plutôt que de commencer directement par l'implémentation, chaque évolution suit désormais un processus structuré.
Vision
↓
Discussion
↓
ADR
↓
Roadmap
↓
Prompt d'implémentation
↓
Codex
↓
Tests
↓
Revue
↓
Commit
Cette approche permet de consacrer davantage de temps aux décisions d'architecture tout en automatisant une partie des tâches répétitives grâce à l'IA.
L'objectif n'est pas de déléguer la conception, mais d'accélérer l'implémentation lorsque les décisions sont déjà clairement établies.
Les enseignements
Cette première phase du projet m'a conforté dans plusieurs idées.
La première est qu'une bonne architecture reste essentielle, même lorsque l'IA est capable de générer du code.
La seconde est que les Architecture Decision Records (ADR) apportent une véritable valeur lorsqu'ils deviennent le point d'entrée de la réflexion technique.
Enfin, cette expérience montre que l'intelligence artificielle est particulièrement efficace lorsqu'elle vient compléter un processus d'ingénierie déjà structuré, plutôt que de le remplacer.
Les prochaines étapes
Les fondations étant désormais en place, la prochaine phase consistera à enrichir progressivement l'intelligence de la plateforme.
Les principales évolutions prévues concernent :
- l'amélioration de la qualité des
AnalysisContext; - l'enrichissement des analyses déterministes ;
- l'apprentissage à partir des validations humaines ;
- la génération automatique de tâches d'implémentation à partir des ADR ;
- la génération assistée de documentation et d'articles techniques.
À terme, DevLog AI ne sera pas uniquement un assistant de développement.
L'objectif est de construire une véritable mémoire d'ingénierie capable d'accompagner durablement les développeurs et les agents IA tout au long de la vie d'un projet.
Conclusion
Cette première étape marque un changement important dans ma manière d'aborder les projets logiciels.
Au-delà de l'intégration d'un modèle de langage, DevLog AI représente une réflexion sur la place de l'intelligence artificielle dans le développement logiciel.
Plutôt que de placer le LLM au centre de l'application, j'ai choisi de construire une architecture où le domaine métier, les décisions techniques et la connaissance du projet restent sous le contrôle du cœur applicatif.
L'intelligence artificielle devient alors un outil puissant d'interprétation et d'assistance, sans jamais remplacer la mémoire ni les décisions d'ingénierie.
Les prochaines évolutions consisteront à enrichir progressivement cette mémoire afin de construire un environnement où développeurs et agents IA collaborent à partir d'une compréhension commune du projet.